Analogy: Recipe card. Step Functions is like a recipe that tells the kitchen (Lambda) what to do step by step. The recipe handles the flow (order, wait, branch), so each cook focuses only on their one task.
Define workflows as state machines (JSON)
Handle orchestration logic OUTSIDE your Lambda code
Keeps Lambda functions focused on business logic only
Auto-generated flow diagram + run history for monitoring
Built-in error handling (retry + catch)
Direct service integrations (200+ AWS services)
States Get Inputs, Do Work, Pass Outputs
State Types
State
Purpose
Analogy
Task
Performs work (Lambda, service API, activity)
A cook making one dish
Choice
Branching logic (if/else based on input)
Fork in the road - which way?
Parallel
Runs branches concurrently, waits for all
Multiple cooks working at once
Map
Iterates over array items (same steps per item)
Assembly line - same process per unit
Wait
Pauses for specific/relative time
Timer on the oven
Pass
Passes input to output (or injects data)
Passing the baton in a relay
Succeed/Fail
Terminates workflow with success or failure
Finish line / stop sign
Task States - Perform the Work
A Task state performs work through:
Lambda function - invoke your code
AWS service API - call DynamoDB, SQS, SNS, etc. directly
Activity - external worker polls for tasks (human approval, on-prem)
Integration Patterns
Pattern
Suffix
Behavior
Request-Response
(none)
Call and immediately continue
Run a Job (.sync)
.sync
Wait until job completes
Callback
.waitForTaskToken
Pause until token returned externally
.sync = oven timer: you put the pie in and WAIT until it's done. Callback = delivery: you order and WAIT until someone knocks on your door with the result.
Choice & Parallel States
Choice = if/else routing. Parallel = run all at once, wait for all to finish.
Map State - Iterate Over Array
Assembly line: Same steps for each donut in the order. Map runs the Iterator once per item in the input array - concurrently!
// Input to Map state
{
"donutorder": "C16",
"ordered": [
{"icing": "sprinkles", "quantity": 4},
{"icing": "chocolate", "quantity": 4},
{"icing": "lemon", "quantity": 4}
]
}
// Map runs: Fry -> Ice -> Box for EACH item in "ordered" array
Map Types
Inline Map - items processed within the workflow (up to 40 concurrent)
Distributed Map - massive scale (10,000+ concurrent), reads from S3
Wait States & Callback Patterns
Pattern
How
Use Case
Wait state
Pause for X seconds or until timestamp
Rate limiting, scheduled delays
.sync
Suffix on Task - waits for job completion
ECS tasks, Glue jobs, Batch jobs
.waitForTaskToken
Pause until external system returns token
Human approval, external API callback
Wait = set a kitchen timer. .sync = put pie in oven, wait until done. Callback = order delivery and wait for doorbell.
Step Functions = universal remote control for AWS services. One state machine can orchestrate DynamoDB + Lambda + SQS + Bedrock without writing glue code.
What's New (2024-2025)
Distributed Map - Process millions of items from S3 (10,000+ concurrent)
Q1: Which state type provides if/else branching logic?
C) Choice - Uses rules to determine the next state based on input values. A: Task does work. B: Parallel runs branches concurrently. D: Map iterates over arrays.
Q2: How do you pause Step Functions until an external system completes?
B) .waitForTaskToken - Pauses execution and passes a token. External system calls SendTaskSuccess/Failure with that token to resume. A: Wait is for fixed delays, not external completion. C: Wastes Lambda execution time. D: Parallel runs things concurrently, doesn't wait for external.
Q3: When should you use Express over Standard workflows?
B) High-volume, short event processing - Express handles 100K+ starts/sec, runs up to 5 min, costs less per execution. A: Express max 5 min; use Standard for hours. C: Express is at-least-once; Standard is exactly-once. D: Express logs to CloudWatch only, no console history.
Q4: What does ResultPath do in the input/output processing?
B) Combines original input with task result - Specifies WHERE in the original input to insert the result. Preserves context. A: That's InputPath. C: That's OutputPath. D: That's Parameters.
Module Summary
Use Step Functions to orchestrate a series of steps
Simplify logic using predefined states and templated code
Task, Choice, Parallel, Map, Wait = core building blocks
Use paths, parameters, and ResultSelector to enrich I/O
Retry + Catch for built-in error handling
Choose Standard (long, auditable) vs Express (fast, high-volume)
200+ direct service integrations reduce Lambda functions needed
Live Demo: Order Processing Workflow
This demo creates a Step Functions state machine that demonstrates: Task, Choice, Parallel, Wait, and error handling.
Architecture
Demo Step 1: Create Lambda Functions
1. Create IAM Role
aws iam create-role --role-name sfn-demo-lambda-role \
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"lambda.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
aws iam attach-role-policy --role-name sfn-demo-lambda-role \
--policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
2. Save state-machine.json (next slide has the full definition)
# Save the JSON definition to a file, then create:
aws stepfunctions create-state-machine \
--name order-processing-demo \
--definition file://state-machine.json \
--role-arn arn:aws:iam::ACCOUNT:role/sfn-demo-execution-role \
--type STANDARD
# Note the state machine ARN from the output
3. Verify in Console
# Open Step Functions console to see the visual workflow:
# https://console.aws.amazon.com/states/home?region=us-west-2#/statemachines
Demo Step 2: State Machine JSON (state-machine.json)